X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C8311B.521F35D5@onstor-exch02.onstor.net>; Tue, 27 Nov 2007 09:31:19 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-class: urn:content-classes:message
Subject: KISS principle
Date: Tue, 27 Nov 2007 09:31:18 -0800
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E06C956E8@onstor-exch02.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: KISS principle
Thread-Index: AcgxG1G/Xfhdg6mvSF2e4NNuXFmvIQ==
From: "Brian DeForest" <brian.deforest@onstor.com>
To: "dl-Design Review" <dl-designreview@onstor.com>,
	"dl-Software" <dl-software@onstor.com>

I thought this was a very good article, and particularly timely.  =20

------------------------------------


When good software gets complicated
By John Hunt=09

...

Keeping it simple

Personally, I am a really big fan of KISS - "keep it simple stupid" -
but what does this mean? It means aiming to produce software that is as
simple as is achievable, but that still gets the job done. And actually,
the ability to keep it simple is certainly not stupid. It is, in fact, a
very hard thing to do and requires a great deal of skill.

Why is this? Surely writing simple software is, well, simple. The
trouble is that what we really want to do is not just write simple
software, but write potentially complex ideas, logic or applications as
simply as possible.

...

Why try harder?

Some of the developers I questioned above asked "why should I bother -
surely as long as the software works that's enough right?" Wrong.
Someone has to maintain the software, someone may need to extend that
software, and someone may need to fix bugs in that software (perish the
thought). The more complex the way it is implemented, the harder it will
be to maintain.

...

Simplicity can be copied

Yet another reason to keep things simple is that the first time you
design and implement a solution to a problem you may well be doing so to
solve a particular problem.

However, this may then become a blueprint to others on how to solve the
same or similar problem elsewhere within the team, project or
organization. If the solution you create is as simple as it can be, then
not only will this approach permeate across the organization, but that
"copied solution" will be easier for others to understand.

You'd be surprised the number of times I have heard the answer "I did it
that way because that was what was done before" when I have asked
(particularly more junior developers) why they adopted a particular
approach. When this is followed up with a question about how the
solution works, on more than one occasion I have received the answer
"not sure really".

Avoid over-engineering

My final comment on keeping it simple is that you should be careful not
to over-engineer solutions. That is, you should only implement what you
need to implement and not attempt to anticipate future needs. Not only
may those needs never actually materialize, but they also make the
software more complex and more difficult to understand (not least as
anyone looking at the code later on may fail to understand why the
additions were included).

Conclusion

There are many reasons for keeping things simple, but there are also
exist a number of "pressures" that may limit the simplicity of the
solution. These pressures can include the desire to produce some fun
code or to "impress other programmers" with your skills. At the end of
the day, though, it's the simplest code that may actually be harder to
write than apparently more complex - but potentially less thought out -
code. (r)


Full article:

http://www.regdeveloper.co.uk/2007/11/26/keeping_software_simple/
